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ABSTRACT: 

Today, a Client and an associated Server use a single IP priority for all the data packets 
exchanged over a TCP session used to transport the Telnet traffic (file transfer and screen 
related interactions). The present invention discloses a method and system to provide the Client 
with the capability, when exchanging a file with an SNA Host over a TCP session, to dynamically 
change (i.e downgrade) the IP priority associated to all data packets flowing to the TN3270 
Server over the TCP session, during the whole duration of the file transfer. The associated 
Server, on receipt of a data packet from the client (due to screen related interactions or to file 
transfers), memorizes the associated priority and uses this priority over all packets that it sends 
back to the client This allows IP network implementation to give higher priority treatment to the 
data packets due to screen related interactions (interactive traffic) over data packets related to file 
transfer (batch traffic). The priority used by data packets related to file transfer is customisable, to 
give maximum freedom to the network designer. For example, SNA true interactive traffic (due to 
screen related interactions) could flow on the highest priority, pure IP traffic could flow on any of 
the possible medium priorities and data packet due to file transfer could use the lowest priority 
within the network. 
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(57) Today, a Client and an associated Server use 
a single IP priority for all the data packets exchanged 
over a TCP session used to transport the Telnet traffic 
(file transfer and screen related interactions). 

The present invention discloses a method and sys- 
tem to provide the Client with the capability, when ex- 
changing a file with an SNA Host over a TCP session 
to dynamically change (i.e downgrade) the IP priority as- 
sociated to all data packets flowing to the TN3270 Serv- 
er over the TCP session, during the whole duration of 
the file transfer. 

The associated Server, on receipt of a data packet 
from the client (due to screen related interactions or to 
file transfers), memorizes the associated priority and us- 
es this priority over all packets that it sends back to the 
client. This allows IP network implementation to give 
higher priority treatment to the data packets due to 
screen related interactions (interactive traffic) over data 
packets related to file transfer (batch traffic). 

The priority used by data packets related to file 
transfer is customisable, to give maximum freedom to 
the network designer. For example, SNA true interactive 
traffic (due to screen related interactions) could flow on 
the highest priority, pure IP traffic could flow on any of 
the possible medium priorities and data packet due to 
file transfer could use the lowest priority within the net- 
work. 
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Description 

Technical field of the invention 

[0001] The present invention relates to digital commu- 
nication networks, more particularly to a method and 
system in an SNA-IP environment for improving overall 
IP network response time during the exchange of files 
between Telnet 3270 Clients and SNA Hosts accessed 
through Telnet 3270 Servers. 

Background art 



ical Unit (LU) in the mainframe and the Logical Unit 
representing the terminal (the TN3270 Client) within 
the Server. 

• a screen session is a session between the TN3270 
Client and the mainframe application. 

♦ a TCP session is a session between the TN3270 
Client and the TN3270 Server. 

[0004] More information concerning the Internet Pro- 
tocols, Telnet, TN3270 and Network Utility can be found 
in the following publications incorporated herewith by 
reference: 
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ENVIRONMENT 
SNA-IP Environment 

[0002] Every day, for all sorts of reasons, more and 
more companies are focusing on the consolidation of 
the multiple specialized networks they directly operate 
or lease from service providers onto a single protocol 
network. These multiple specialized networks are based 
on diverse networking technologies such as Systems 
Network Architecture (SNA), Internet Protocol (IP) or In- 
ternetwork Packet Exchange (IPX). These companies 
are making this consolidation one of their top priorities, 
they are almost exclusively selecting IP (the Internet 
Protocol) as their protocol of choice. However, for the 
overwhelming majority of these companies that are us- 
ing SNA protocols and applications, there still is and will 
be for the many years to come, a major requirement in 
this changing environment. The requirement is for the 
employees of these companies to keep the capability 
they always had to have access to the huge amount of 
existing corporate data residing in traditional main- 
frames and accessible through SNA applications. 

TN3270 

[0003] In an IP environment, a widely used technique 
for the transport of SNA information across an IP net- 
work is the use of Telnet technologies (TN3270). This 
technique for SNA "green screen" workstation users is 
a Client/Server approach. "Host On Demand" from IBM 
or "WebClient" from CISCO are examples of Client soft- 
ware implementations. Network Utility from IBM or CIS- 
CO router's offerings are typical Server implementations 
(hardware and software). The "Client" piece usually 
runs within the customer's workstation while the "Serv- 
er" piece is usually placed in front of the customer's Data 
Center mainframes (or sometimes directly within the 
mainframe itself) or within the customer's branch offices. 
As illustrated in Figure 3, IP protocols are used between 
the Server and the Clients, while traditional SNA proto- 
cols are used between the Server and the target Appli- 
cations. The different kinds of sessions are shown: 

* an SNA session is a session between an SNA Log- 



is 



20 



30 



35 



"Systems Network Architecture Technical Over- 
view", Fifth Edition (January 1 994), GC30-3073-04. 
"IBM 2216/Network Utility Host Channel Connec- 
tion", Erol Lengerli, Jacinta Carbonell, Thomas Gru- 
eter; I BM International Technical Support Organiza- 
tion, January 1999, SG24-5303-00. 
"IBM Network Utility Description and Configuration 
Scenarios", Tim Kearby, Peter Gayek, Gallus Sch- 
legel, Imre Szabo, Zhi-Yong Zhang; IBM Interna- 
tional Technical Support Organization, January 
1999, SG24-5289-00. 
25 • "TCP/IP Tutorial and Technical Overview", M. Mur- 
hammer, O. Atakan, S. Bretz, L. Pugh, K. Suzuki, 
D. Wood; IBM International Technical Support Or- 
ganization, Sixth Edition (October 1998), 
GG24-3376-05. 

"Internetworking with TCP/I P - Volume I - Principles, 
Protocols, and Architecture" Douglas E.Comer, 
Second Edition, Prentice Hall 1991. 
Request For Comments (RFCs) from the Internet 
Engineering Task Force (IETF): 

• RFC 1576: TN3270 Current Practices, 

• RFC 1646: TN3270 Extensions for LU name 
and Printer Selection, 

• RFC 1647: TN3270 Enhancements, 
40 • RFC 2355: TN3270 Enhancements, 

• RFC 2474; Definition of the Differentiated Serv- 
ice Filed (DS Field) in the IPv4 and IPv6 Head- 
ers, 

• RFC 2475: An Architecture for Differentiated 
45 Services, 

• RFC 1 349: Type of Service in the Internet Pro- 
tocol Suite. 

FILE TRANSFER 

50 

[0005] Telnet 3270 protocols specify that Clients are 
connected to the hosts via TN3270 Servers. Tradition- 
ally, in SNA environments, the data traffic related to 
screen interaction between a terminal and a host appli- 
es cation is characterized as interactive traffic, while the 
data traffic related to the transfer of files is characterized 
as batch traffic. Telnet 3270 and SNA Protocols offer to 
TN3270 Clients the capability to download within the lo- 
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cal workstation where the Client operates, files from the 
host(s) they are connected to. Similarly, it is possible for 
a Client to upload files from the local workstation to SNA 
Hosts the Client is in session with. 

s 

PROBLEM STATEMENT 

[0006] When a TN3270 Client exchanges files with an 
SNA Host across a Telnet Server, the packets of infor- 
mation related to the file being exchanged are sent be- « 
tween the Client and its Server using the same sessions 
(TCP, Screen and SNA sessions as illustrated in Figure 
3) than those used for screen related interactions. This 
means that data packets related to the transfer of files 
are using the same priority than the priority used for the is 
interactive traffic due to screen related interactions. This 
mode of operation violates SNA fundamental rules as- 
sociated with SNA Class Of Service (COS) and Trans- 
mission Priority (TP) within SNA networks. These rules 
assume that interactive traffic (such as screen related 20 
interactions) gets a better treatment within the network 
than lower priority traffic such as batch traffic (such as 
file transfer related traffic). 

[0007] Transfer of large files between Clients and 
their Servers generate a huge amount of data packets 2s 
that should not flow on the same priority as the interac- 
tive, screen related traffic. As a differentiation is not 
made, overall response time is severely impacted as 
now, the true interactive traffic but also the non-SNA da- 
ta traffic will be penalized by a flooding of data packets 30 
related to the exchange of files across the network. Ex- 
changing files consumes bandwidth and processing re- 
sources within the network. In fact, from an SNA stand- 
point, the packets related to the exchange of files be- 
tween a Client and its Server shou Id have a lower priority 3S 
than the real interactive traffic allowing the higher priority 
traffic to get a better service than any other low priority 
traffic. 

[0008] Figure 1 provides a schematic view of two traf- 
fic sources (TN3270 Clients) connected to a destination 40 
(a TN3270 Server) across an IP Network. From an IP 
network standpoint, as there is no differentiation be- 
tween the data traffic due to screen related interactions 
and the data traffic related to file transfer, all SNA pack- 
ets are treated the same. The network may be repre- 45 
sented as a single queue, with a first come first serve 
quality of service. 

[0009] In summary, SNA traffic for interactive traffic 
(screen related interactions) is impacted by the transfer 
of files. Similarly, non-SNA traffic (such as pure IP data so 
traffic), usually flowing on a lower priority than SNA traf- 
fic is also impacted by the potential network flooding due 
to data packets exchanged across the network during 
file transfer. 

[0010] The present invention proposes a solution ss 
within the IP network, to get around this response time 
problem. 



Objects of the invention 

[0011] It is an object of the present invention to allow 
TN3270 Clients to dynamically specify a lower IP priority 
for the traffic related to the exchange of files (batch traf- 
fic), than the priority associated to the traffic due to 
screen related interactions (interactive traffic). 
[0012] It is a further object of the present invention to 
allow a TN3270 Server to use the same priority as the 
priority used by the Client when exchanging information 
with the Client 

Summary of the invention 

[001 3] The present invention discloses a method and 
system to provide the Client with the capability, when 
exchanging a file with an SNA Host over a TCP session, 
to dynamically change (i.e downgrade) the IP priority as- 
sociated to all data packets flowing to the TN3270 Serv- 
er over the TCP session, during the whole duration of 
the file transfer. 

[0014] The associated Server, on receipt of a data 
packet from the client (due to screen related interactions 
or to file transfers), memorizes the associated priority 
used within the TCP session and uses this priority over 
all packets that it sends back to the client over this TCP 
session. This allows network implementation to give 
higher priority treatment to the data packets due to 
screen related interactions (interactive traffic) over data 
packets related to file transfer (batch traffic). 
[001 5] The priority used by data packets related to file 
transfer is customisable, to give maximum freedom to 
the network designer. For example, SNA true interactive 
traffic (due to screen related interactions) could flow on 
the highest priority, pure IP traffic could flow on any of 
the possible medium priorities and data packet due to 
file transfer could use the lowest priority within the net- 
work. 

Drawings 

[0016] The novel and inventive features believed 
characteristics of the invention are set forth in the ap- 
pended claims. The invention itself, however, as well as 
a preferred mode of use, further objects and advantages 
thereof, will best be understood by reference to the fol- 
lowing detailed description of an illustrative detailed em- 
bodiment when read in conjunction with the accompa- 
nying drawings, wherein ; 

* Figure 1 shows how packets from two different 
sources are processed across an IP network, when 
file transfer and screen related interactions both use 
the same IP priority. 

• Figure 2a shows various steps performed within the 
Client according to the present invention. 
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• Figure 2b shows various steps performed within the 
Server according to the present invention. 

• Figure 3 shows an access to SNA Applications in a 
Telnet 3270 Environment. 

Preferred embodiment of the invention 

SNA-IP ENVIRONMENT 

Extension of networks 

[0017] To remain competitive, network users are ex- 
tending their traditional internal SNA and IP networks 
outward to business partners, dealers, suppliers, and 
customers. In this expanding environment, users are al- 
so searching for ways to save money and provide con- 
nectivity between their mix of SNA and TCP/IP server 
applications and their TCP/IP and SNA desktop client 
population. 

Consolidation of networks 

[0018] Many companies tod^y are considering the 
consolidation of their WAN traffic onto a single IP-only 
backbone. At the same time, other companies are sim- 
plifying their workstation configurations and attempting 
to run only the TCP/IP protocol stack at the desktop. 
However, most of these companies still require access 
to SNA applications hosts. 



TN3270 

[001 9] TN3270 meets these requirements by allowing 
the end user to run IP from the desktop over the network 
and attach to his SNA host through a TN3270 server. 
The clients connect to the server using TCP connec- 
tions. The server provides a gateway function for the 
downstream TN3270 clients by mapping the client ses- 
sions to SNA-dependent LU-LU sessions that the server 
maintains with the SNA host. The TN3270 server han- 
dles the conversion between the TN3270 data stream 
and an SNA 3270 data stream. 
[0020] As mentioned above, the path from a TN3270 
client to the SNA host consists of: 

1. A TCP connection over IP from the client to the 
server; 

2. An SNA LU-LU session from the server to the 
host; Connecting to a host for establishing an LU- 
LU session can be accomplished using a traditional 
subarea connection or using an APPN connection. 



w 



the TCP/IP stack in the workstation. A given client prod- 
uct provides one of two possible levels of standards sup- 
port: 

• Base TN3270 client; 

These clients conform to RFC 1576 (TN3270 Cur- 
rent Practices) and/or RFC 1646 (TN3270 Exten- 
sions for LU name and Printer Selection). 

• TN3270E client 

These clients conform to RFC 1647 (TN3270 En- 
hancements), and RFC 2355 (TN3270 Enhance- 
ments). 



[0022] A server implementation that can support 
is TN3270E clients is called a TN3270E server. 

[0023] The TN3270 server function can be placed in 
a variety of products and positions within a network, in- 
cluding: 

20 • in the SNA host itself; 

♦ in a router in front of the data host or within the net- 
work or 

• in a specialized box within the network; 

25 SNA CLASS OF SERVICE AND TRANSMISSION 
PRIORITY 



[0024] In SNA, Transmission Priority and Classes Of 
Service (COS) enable equal service to be provided to 
30 sessions of equal priority, or preference given to ses- 
sions of higher priority. The specified COS for a session 
to be established is used to select the best route across 
the network to satisfy the desired characteristics for the 
session, and defines the Transmission Priority that the 
55 SNA packets related to this session will use when flow- 
ing across the network. In an SNA network, different 
Classes Of Service can be specified, based upon the 
needs of the end users in the network. End users typi- 
cally require sessions with widely varying data transmis- 
*o sion requirements. A range of Classes Of Service can 
therefore be provided to accommodate their session re- 
quirements. For example, the following Classes Of 
Service can exist in a network; 



45 
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A class that provides response times suitable for 
high priority interactive sessions; 

• A class that provides response times suitable for 
low priority interactive sessions; 

• A class suitable for Batch processing; 

• A class suitable for high security transmissions. 

IP TRANSMISSION PRIORITY 



[0021] To deploy a TN3270 solution, TN3270 client 
software is installed on desktop workstations and ss 
TN3270 server software is installed in one of several 
places discussed below. Client software is available 
from IBM and many other vendors, and runs on top of 



[0025] A TOS (Type Of Service) field is included in the 
Service Type byte of the IP Header. The Service Type 
is an indication of the quality of service requested for 
the IP datagram and is composed of three parts: the 
Precedence, the TOS and the MBZ parts. 
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• The Precedence is a measure of the nature and pri- 
ority of this datagram; the following values are de- 
fined (Routine, Priority, Immediate, Flash, Flash 
override, Critical, Internetwork control, Network 
control). 

• The Type Of Service (TOS) specifies the type of 
service value (Minimize delay, Maximize through- 
put, Maximize reliability, Minimize monetary cost, 
Normal service). 

• The M8Z is reserved for future use. 

[0026] The Differentiated Services (DS) concept is 
currently under development at the Internet Engineering 
Task Force (IETF) DS working group. The goal of the 
DS development is to get a possibility to provide differ- 
entiated classes of service for Internet traffic, to support 
various types of applications, and specific business re- 
quirements. The Differentiated Services (DS) offers pre- 
dictable performance (delay, throughput, packet loss, 
etc.) for a given load at a given time. The DS byte uses 
the space of the TOS octet in the IP header. All network 
traffic receives a service that depends on the traffic class 
that is specified in the DS byte. 

TRANSMISSION PRIORITY IN SNA-IP 
ENVIRONMENT 



15 



[0027] Today a Client and an associated Server use 
a single IP priority for all the data packets exchanged 
over a TCP session used to transport the Telnet traffic 
(file transfer and screen related interactions). 
[0028] The present invention discloses a method and 
system to provide the Client with the capability, when 
exchanging a file with an SNA Host over a TCP session, 
to dynamically change (i.e downgrade) the IP priority as- 
sociated to all data packets flowing to the TN3270 Serv- 
er over the TCP session, during the whole duration of 
the file transfer. 

[0029] The associated server, on receipt of a data 
packet from the client (due to screen related interactions 
or to file transfers), memorizes the associated priority 
and uses this priority over all packets that it sends back 
to the client. This allows network implementation to give 
higher priority treatment to the data packets due to 
screen related interactions (interactive traffic) over data 
packets related to file transfer (batch traffic). 
[0030] The priority used by data packets related to file 
transfer is customisable, to give maximum freedom to 
the network designer. For example, SNA true interactive 
traffic (due to screen related interactions) could flow on 
the highest priority, pure IP traffic could flow on any of 
the possible medium priorities and data packet due to 
file transfer could use the lowest priority within the net- 
work. 

[0031] A preferred embodiment for the invention isde- 
scribed in two parts, the Client part (Figure 2a) and the 
Server part (Figure 2b). 



CLIENT 

[0032] As described in Figure 2a: 

s • (201) The Client detects that a file transfer takes 
place between the Client and the Server (file trans- 
fer is always performed as a result of an initiative 
from the Client). This file transfer takes place within 
the same TCP session that also carries data pack- 
10 ets for screen related interactions. 

• (202) The Client decides which priority has to be 
used and selects it. In a preferred embodiment, the 
priority used for screen related data transfers is re- 
duced (the amount of reduction is customizable). 
This provides an IP priority lower than the one used 
for true interactive traffic (now used only for screen 
related interactions). 

(203) The Client sets up a local network Device 
Driver for the IP protocol stack in the workstation, 
to use the selected IP packet priority during the 
whole duration of the data transfers related to the 
file exchange. 

• (204) The Client detects the termination of the file 
transfer, 

25 • (205) The Client restores the network Device Driver 
to use the screen related data transfer priority, this 
is done to use the right priority associated to the 
transfer of data packet related to the traffic due to 
screen related interactions. 

[0033] The details related to Device Driver manipula- 
tion will not be described further as this is specific to 
particular workstation hardware and software combina- 
tions. A person skilled in the state of the art can easily 
work out the required details of these specifics. 

SERVER 
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[0034] For each TCP session between a Client and a 
Server, there is an associated priority to be memorized 
by the Server. At Server initialization time, the memo- 
rized priority is initialized with an arbitrary value (such 
as the IP priority to be used for screen related interac- 
tions). The Server determines the priority of the last 
packet received from the Client. The Server compares 
the last packet priority previously determined with the 
memorized priority for this TCP session. If they differ, 
the memorized priority is set (208) to the last packet re- 
ceived priority, and the Server sets up a local network 
Device Driver for the IP protocol stack in the workstation, 
to use the memorized IP packet priority for all packets 
sent to the Client over this TCP session. 
[0035] As described in Figure 2b, the Server: 

• (206) determines the priority of the last packet re- 
ceived from the Client in the TCP session. 

• (207) compares the priority of the last packet ac- 
cording to step (206) with the memorized priority of 
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the TCP session. • If priorities are the same, the 
packet priority is not changed. 
• If priorities are not the same: 

• (208) the memorized priority of the TCP ses- s 
sion is replaced by the priority of the last re- 
ceived packet of the TCP session. 

« (209) the Server sets up a local network Device 
Driver for transmitting with the new memorized 
IP packet priority, all packets to the Client over to 
the TCP session. 



claims wherein it comprises the further steps of: 

• detecting (204) the end of the file traffic; 

• restoring (205) the device driver with the inter- 
active traffic IP transmission priority. 

6. The method according to any one of the preceding 
claims wherein : 

• the telnet client is a telnet 3270 client; and 



[0036] The manipulation of the priorities for the IP 
packets is done in accordance with RFC 1 349, 2474 and 
2475, or any other proprietary scheme. 
[0037] While the invention has been particularly 
shown and described with reference to a preferred em- 
bodiment, it will be understood that various changes in 
form and detaiLmay be made therein without departing 
from the spirit, and scope of the invention. 



* the telnet server is a telnet 3270 server. 

is 7. The method according to any one of the preceding 
claims wherein the application is a systems network 
architecture (SNA) application. 

8. The method according to any one of the preceding 
20 wherein: 



Claims 

1 . A method in a telnet client for transmitting in a ses- 25 
sion, file traffic to an application through a telnet 
server in an Internet protocol (IP) network, said 
method comprising the steps of: 

• assigning (202) an IP transmission priority to so 
file traffic different from the IP transmission pri- 9. 
ority used for interactive traffic: 



transmitting (203) the file traffic to the telnet 
server using said assigned I P transmission pri- 35 
ority. 



2. The method according to the preceding claim 
wherein: 11. 

40 

• the IP transmission priority used for file traffic 
is lower than the IP transmission traffic used for 
transmitting interactive traffic. 

3. The method according to any one of the preceding 45 
claims wherein it comprises the further step of: 



* file traffic between telnet client and telnet server 
is transmitted on a Transmission Control Pro- 
tocol (TCP) session; 

• file traffic between telnet server and systems 
network architecture (SNA) application is trans- 
mitted on a systems network architecture 
(SNA) session. 

A system, in particular a telnet client, comprising 
means adapted for carrying out the method accord- 
ing to any one of the preceding claims. 



10. A computer readable medium comprising instruc- 
tions for carrying out the method according to any 
one of claims 1 to 8. 



A method in a telnet server for transmitting in a ses- 
sion, traffic from an application to a telnet client in 
an Internet protocol (IP) network, said method com- 
prising the steps of: 

• detecting (206) and memorizing (208) the IP 
transmission priority associated the traffic re- 
ceived from the telnet client; 



• detecting (201) the file traffic to be transmitted • transmitting (209) traffic received from the ap- 
to the application through the telnet server. plication to the telnet client using the memo- 

50 rized I P transmission priority associated to the 

4. The method according to any one of the preceding traffic previously received from the telnet client, 
claims wherein it comprises the further step of: 

12. The method according to any one of the preceding 

• setting up (203) a device driver for transmitting claims wherein it comprises the further step of: 
the file traffic with the assigned file traffic IP ss 

transmission priority. • setting up (209) a device driver for transmitting 

the traffic with the IP transmission priority as- 

5. The method according to any one of the preceding sociated to the traffic previously received from 
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the telnet client. 

13. The method according to any one of the preceding 
claims wherein : 

5 

• the telnet client is a telnet 3270 client; and 

• the telnet server is a telnet 3270 server. 

1 4. The method according to any one of the preceding ?o 
claims wherein the application is a systems network 
architecture (SNA) application. 

15. The method according to any one of the preceding 
wherein: is 

• traffic between telnet client and telnet server is 
transmitted on a Transmission Control Protocol 
(TCP) session; 

20 

• traffic between telnet server and systems net- 
work architecture (SNA) application is transmit- 
ted on a systems network architecture (SNA) 
session. 

25 

16. A system, in particular a telnet server, comprising 
means adapted for carrying out the method accord- 
ing to any one of the claims 11 to 15. 

17. A computer readable medium comprising instruc- 30 
tions for carrying out the method according to any 
one of claims 11 to 15. 
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CLIENT IMPLEMENTATION 
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BEGINNING OF FILE TRANSFER 


(201) 








SELECT PRIORITY TO USE 


(202) 








SET-UP DEVICE DRIVER TO 
USE THE SELECTED PRIORITY 


(203) 








END OF FILE TRANSFER 


(204) 








RESTORE DEVICE DRIVER TO 
USE THE SREEN PRIORITY 


(205) 









FIG.2A 
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SERVER IMPLEMENTATION 



SERVER DETERMINES LAST RECEIVED PACKET PRIORITY 



YES 



< 
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